In some palmtop computer systems, all services or applications running on the operating system are required to run through a single thread (e.g., task). Typically, this thread is a foreground thread. While the operating system is classified as multitasking, all user interfacing and most resource related activities are done under the foreground thread. In these computer systems, all services, whether they are related to system activities, interrupt activities, background activities, or foreground activities, must operate to some extent in the foreground thread.
Under current system architecture, the operating system comprises a kernel. The kernel provides many essential functions required by the operating system and other services. Among these essential functions is operating a scheduler. The kernel allows the operating system to allocate slices of time (e.g., execution context) and memory (e.g., data context) of the foreground thread to services, typically as they are ordered in an event queue. The kernel essentially operates as a traffic light, allocating resources to tasks as they are ranked in priority.
Once a service receives an execution context, the operating system is dependent on the service ceding control of the foreground thread. If a service does not cede control of the foreground thread, other services are prevented from operating. Ail activities operating on the foreground thread must be disciplined enough to allow that to happen or else the operating system comes to a halt. This is not often the case, as background-related activities (e.g., hardware management, communications protocols, and infrared protocols) are required to share the operating system with foreground related activities (e.g., the graphical user interface). If a foreground activity does not cede control of the foreground thread, background activities are prevented from operating.
Additionally, some computer operating systems do not provide a mechanism where third party applications and tasks can access the kernel for receiving an execution presence independent of the foreground tasks. For example, some kernel developers do not like to give out their code to third party developers, thus further limiting the number of predetermined services that are hardwired into the kernel. In these operating systems, kernel access is prohibited to third party developers. Thus, it is not possible for third party applications to receive an execution context from the scheduler, thus preventing the third party applications from operating.
Palmtop computer systems, as with most computer systems, often have a number of interrupt service routines. For an interrupt service routine to be reliably executed on many palmtop computer systems, the interrupt must be pre-built into the operating system. A pre-built interrupt is contained in a reserved area on the operating system. A number of users often desire to install third party interrupt service routines into their palmtop computer systems.
The only way to add an interrupt service routine after the operating system is built is to couple the interrupt routine to the foreground task. This does not provide a reliable interrupt routine because it cannot be predicted with certainty if the interrupt will receive its time to run. Current third party interrupt service routine developers are forced to rely on the behavior of the foreground task in granting the service routine time to run.
Currently, no mechanism exists to permit third party interrupt service routines to operate reliably, other than pre-building them into the operating system. Thus, third party interrupt service routines may not be reliably executed on the current system architecture.